<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="en" xml:lang="en" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<head>
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Concept: Design</title>
<meta name="uma.type" content="Concept">
<meta name="uma.name" content="design">
<meta name="uma.presentationName" content="Design">
<meta name="element_type" content="concept">
<meta name="filetype" content="description">
<meta name="role" content="">
<link rel="StyleSheet" href="./../../../css/default.css" type="text/css">
<script src="./../../../scripts/ContentPageResource.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageSubSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageToolbar.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/contentPage.js" type="text/javascript" language="JavaScript"></script><script type="text/javascript" language="JavaScript">
					var backPath = './../../../';
					var imgPath = './../../../images/';
					var nodeInfo=null;
					contentPage.preload(imgPath, backPath, nodeInfo,  '', false, false, false);
				</script>
</head>
<body>
<div id="breadcrumbs"></div>
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tr>
<td valign="top"><a name="Top"></a>
<div id="page-guid" value="_bFjlAPTYEduDKIuqTXQ8SA"></div>
<table border="0" cellspacing="0" cellpadding="0" width="100%">
<tr>
<td class="pageTitle" nowrap="true">Concept: Design</td><td width="100%">
<div align="right" id="contentPageToolbar"></div>
</td><td width="100%" class="expandCollapseLink" align="right"><a name="mainIndex" href="./../../../index.htm"></a><script language="JavaScript" type="text/javascript" src="./../../../scripts/treebrowser.js"></script></td>
</tr>
</table>
<table width="100%" border="0" cellpadding="0" cellspacing="0">
<tr>
<td class="pageTitleSeparator"><img src="./../../../images/shim.gif" alt="" title="" height="1"></td>
</tr>
</table>
<div class="overview">
<table width="97%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td width="50"><img src="./../../../images/concept.gif" alt="" title=""></td><td>
<table class="overviewTable" border="0" cellspacing="0" cellpadding="0">
<tr>
<td valign="top">This concept outlines important principles that should be taken into account when considering the design of a system.</td>
</tr>
</table>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Relationships</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<th class="sectionTableHeading" scope="row">Related Elements</th><td class="sectionTableCell">
<ul>
<li>
<a href="./../../../practice.tech.evolutionary_design.base/guidances/guidelines/analyze_the_design_4C4750C0.html" guid="__MnggPTdEduDKIuqTXQ8SA">Analyze the Design</a>
</li>
<li>
<a href="./../../../practice.tech.evolutionary_design.base/workproducts/design_D677D182.html" guid="_0WuL8slgEdmt3adZL5Dmdw">Design</a>
</li>
<li>
<a href="./../../../practice.tech.evolutionary_design.base/tasks/design_solution_A97CE9EA.html" guid="_0fshwMlgEdmt3adZL5Dmdw">Design the Solution</a>
</li>
<li>
<a href="./../../../practice.tech.evolutionary_design.base/guidances/guidelines/evolve_the_design_3C9D6965.html" guid="_C4U9QPTeEduDKIuqTXQ8SA">Evolve the Design</a>
</li>
</ul>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Main Description</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td class="sectionTableSingleCell"><p>
    Designing a system is about creating the internal structure and behavior of a system that's robust, extensible, and
    high-quality. Good design improves quality and makes a system easier to maintain and extend, while a poor design can
    significantly raise the cost of producing and maintaining the software.
</p>
<p>
    Design is an abstraction of the code that presents the system from a perspective that makes it easier to address the
    structure and behavior of the software. This can be done through viewing the code, but it's more difficult and less
    effective to address structural and behavioral issues this way. Design can be visual models, simple sketches, text
    descriptions, etc. The critical element of design is that it describes how different elements of the system interact to
    fulfill the requirements.
</p>
<p>
    The amount of design that's formally documented and maintained will vary depending on the criticality of the design and
    how much of the design needs to be communicated to future team members. At a minimum, all architecturally significant
    design elements should be documented and kept up-to-date with the implementation. These are critical aspects of the
    system that are necessary for the understanding and maintenance of the software. Other important or complex structure
    and behavior may be maintained as well. And some contracts may require that the entire design is thoroughly documented.
</p>
<p>
    On many projects there will probably be aspects of the design that are only documented for the purpose of creating a
    solution or walking through how certain behavior will be realized. It may not be worth the overhead of maintaining this
    information as the design is transformed through refactoring and other influences. However, it may be useful to archive
    the initial decisions, whiteboard images, or files so they can be referenced in the future if necessary. These can be
    viewed as "old meeting minutes" that are stored for potential future reference. They may not reflect the current
    design, but they may still provide useful insight.
</p>
<h3>
    Multiple Passes
</h3>
<p>
    The design will be revisited many times throughout an iterative lifecycle and even within an iteration. Each time some
    design activity is being performed, it will be performed in the context of a specific goal. The goal might be to
    identify a notional set of participants in a collaboration that can be exercised to realize the behavior required (an
    analysis pass). The goal might be in the identification of some coarse-grained elements that are required to act out
    some scenario (an architectural pass). Then a pass might be done within one of those components to identify the
    elements within that will collaborate together to perform the behavior required (a more detailed design pass).<br />
    <br />
    Design might be performed in a particular context such as database context, user-interface context, or perhaps the
    context of how some existing library will be applied. In these cases the design steps will be performed just to make
    and communicate decisions regarding that context
</p>
<p>
    Avoid analysis paralysis. Avoid refining, extending, and improving the design beyond a minimal version that suffices to
    cover the needs of the requirements within the architecture. Design should be done in small chunks, proven via
    implementation, improved via refactoring, and integrated into the baseline to provide value to the stakeholders.
</p>
<h3>
    Design versus Architecture
</h3>
<p>
    Design is a real thing, the construction of the system's structure and behavior. Architecture defines principles,
    contexts, and constraints on the system's construction. Architecture is described in architecture artifacts, but it's
    realized as design (visual or otherwise) and implementation.<br />
    <br />
    One way to look at architecture is that it helps to make the entire design more cohesive with itself by balancing the
    needs of the entire system. Design tends to focus on one area at a time. Architecture helps assure the design is
    consistent and appropriate to the goals of the system. For instance, there may be constraints placed on most of the
    design to support the performance of one part of the system, such as improving access to a legacy system. Failure to
    conform to those constraints in the design may cause the system to fail to meet the performance requirements of the
    legacy system access. Conforming to the architecture assures that all the goals of the system are met by balancing
    competing technical issues.
</p>
<h3>
    Quality of Design
</h3>
<h4>
    You Aren't Going to Need It
</h4>
<p>
    The YAGNI principle is a good general approach to design. While designs should be robust enough to modify, re-use, and
    maintain, it should also be as simple as possible. One of the ways to keep it simple is to make few assumptions about
    what the design's going to need in the future. Don't assume you'll need something until you know you need it, then do a
    good job of adding it. Add what's needed for the current requirement or iteration. Refactor the design as necessary
    when more functionality needs to be added or the design must be made more complex to deal with new circumstances.
</p>
<h4>
    Coupling and Cohesion
</h4>
<p>
    Two of the most fundamental principles of design are coupling and cohesion. A good design contains elements that have
    high cohesion and low coupling. High cohesion means that a single element, such as a class or subsystem, is composed of
    parts that are closely related or work closely together to fulfill some purpose. Low coupling means that the elements
    of a system have a minimum of dependencies on each other. A single element such as a subsystem should be easily
    replaceable by another subsystem that provides similar behavior.<br />
    <br />
    For example, in a payroll system an Employee class would have high cohesion if it contained elements and functions such
    as Name, Tax ID Number, and Monthly Salary. At first, it may seem as if the Calculate Paycheck functional would also be
    cohesive. But when you consider that hourly employees must be paid overtime, sales people must have commission
    calculated for them, etc, the function is less related to Employee and should probably be its own class or
    subsystem.<br />
    <br />
    An example of low coupling would be if the Calculate Paycheck subsystem can be easily replaced by third party that may
    be more robust and offer more features.<br />
    <br />
    Coupling and cohesion are so important to be aware of because they arise in so many design principles and design
    strategies such as patterns.
</p>
<h4>
    Open-Closed Principle
</h4>
<p>
    Elements in the design should be "open" for extension but "closed" for modification. The goal of this principle is to
    create software than can be extended without changing code&nbsp;<a class="elementLinkWithUserText" href="./../../../core.default.nav_view.base/guidances/supportingmaterials/references_C6FF2A8D.html#MEY97" guid="__nHToFndEd2EdJKkAyeBng">[MEY97]</a>. This is because every change to software runs the risk of introducing bugs
    into code that's already correct. It also allows functionality to be re-used without having to know the details of the
    implementation, reducing the time it takes to create something new. Keeping this principle in mind helps make a design
    more maintainable.<br />
</p>&nbsp;</td>
</tr>
</table>
</div>
<div class="sectionHeading">More Information</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<th class="sectionTableHeading" scope="row">Checklists</th><td class="sectionTableCell">
<ul>
<li>
<a href="./../../../practice.tech.evolutionary_design.base/guidances/checklists/design_68980812.html" guid="_0XSzsMlgEdmt3adZL5Dmdw">Design</a>
</li>
</ul>
</td>
</tr>
<tr valign="top">
<th class="sectionTableHeading" scope="row">Concepts</th><td class="sectionTableCell">
<ul>
<li>
<a href="./../../../core.tech.common.extend_supp/guidances/concepts/refactoring_1B63BA3B.html" guid="_Poc7IPDzEdqYgerqi84oCA">Refactoring</a>
</li>
<li>
<a href="./../../../core.tech.common.extend_supp/guidances/concepts/software_architecture_59A08DE0.html" guid="__O7tAMVvEduLYZUGfgZrkQ">Software Architecture</a>
</li>
</ul>
</td>
</tr>
</table>
</div>
<table class="copyright" border="0" cellspacing="0" cellpadding="0">
<tr>
<td class="copyright"><p> This program and the accompanying materials are made available under the<br />
  <a href="http://www.eclipse.org/org/documents/epl-v10.php" target="_blank">Eclipse 
  Public License V1.0</a>, which accompanies this distribution. </p><p/><p> <a class="elementLink" href="./../../../core.default.release_copyright.base/guidances/supportingmaterials/openup_copyright_C3031062.html" guid="_UaGfECcTEduSX6N2jUafGA">OpenUP Copyright</a></p></td>
</tr>
</table>
</td>
</tr>
</table>
</body>
<script type="text/javascript" language="JavaScript">
				contentPage.onload();
			</script>
</html>
